home *** CD-ROM | disk | FTP | other *** search
/ The X-Philes (2nd Revision) / The X-Philes Number 1 (1995).iso / xphiles / hp48hor1 / argcheck.doc < prev    next >
Text File  |  1995-03-31  |  2KB  |  30 lines
  1. [A note about RPL argument type checking w/o bogus XLIB error messages.  -jkh] 
  2.  Author: [Joseph James Ervin] 
  3.  Date: Wed Mar 06 1991 
  4.  
  5. In the course of doing some system RPL proramming, I had need to do argument 
  6. checking, so I wanted to use the RPL instructions that do this.  I had my 
  7. choice between one that said "save last RPL token" and one that said "set last 
  8. RPL token to <0h>".  I tried both.  There was a significant difference. 
  9.  
  10. When I used the command that said "save last RPL token", I got a strange XLIB 
  11. number when the parameter check failed.  When I used "set last RPL token to 
  12. <0h>" the code which prints out the error message did not attempt to display 
  13. the XLIB that generated the error. 
  14.  
  15. In other words, did you ever wonder how the machine knows, when you hit + with 
  16. no arguments, that it should include "+" in the error message to tell you what 
  17. command (e.g. XLIB) generated the error?  My guess is that the "last RPL 
  18. token" is just a variable somewhere into which is stored the ID of the most 
  19. recent RPL token.  When something goes wrong and an error message must be 
  20. displayed, the system will pull the saved ID out of this variable and use it in 
  21. the error message.  By using system RPL routines that say "set last RPL token 
  22. to <0h>", the system flags this variable as containing bogus data, and that it 
  23. should not be used in error messages.  I have no idea what other things this 
  24. "last RPL token" variable may be used for. 
  25.  
  26. Please keep in mind that this is just my guess based on my own observations. 
  27. Oh, by the way, Bill Wickes uses the "set LAST RPL token to <0h>" in his ASC 
  28. routines.  That's why when you feed ASC bad parameters, the error message makes 
  29. no attempt to identify ASC as the command that generated the error. 
  30.